src/modules/reverse-proxy/table/ReverseProxyAccessControlCell.tsx (1)

110-117: Consider applying the same IPv6 fix to existing allowed/blocked CIDR filtering.

For consistency, the allowed/blocked IP filtering at lines 110-117 should also handle /128 suffixes if IPv6 support is being added across the feature.

Example fix for existing filters

     const allowedIps =
-      restrictions?.allowed_cidrs?.filter((c) => c.endsWith("/32")) ?? [];
+      restrictions?.allowed_cidrs?.filter((c) => c.endsWith("/32") || c.endsWith("/128")) ?? [];
     const allowedCidrs =
-      restrictions?.allowed_cidrs?.filter((c) => !c.endsWith("/32")) ?? [];
+      restrictions?.allowed_cidrs?.filter((c) => !c.endsWith("/32") && !c.endsWith("/128")) ?? [];
     const blockedIps =
-      restrictions?.blocked_cidrs?.filter((c) => c.endsWith("/32")) ?? [];
+      restrictions?.blocked_cidrs?.filter((c) => c.endsWith("/32") || c.endsWith("/128")) ?? [];
     const blockedCidrs =
-      restrictions?.blocked_cidrs?.filter((c) => !c.endsWith("/32")) ?? [];
+      restrictions?.blocked_cidrs?.filter((c) => !c.endsWith("/32") && !c.endsWith("/128")) ?? [];

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/modules/reverse-proxy/table/ReverseProxyAccessControlCell.tsx` around
lines 110 - 117, Update the CIDR filtering in ReverseProxyAccessControlCell.tsx
so the allowed/blocked IP lists treat IPv6 host addresses the same as IPv4:
change the .endsWith("/32") checks used to populate allowedIps and blockedIps to
also accept "/128" (e.g., treat strings that end with "/32" OR "/128" as
single-host IPs) and invert that logic for allowedCidrs and blockedCidrs (keep
entries that do not end with "/32" AND do not end with "/128"); update the
expressions that compute allowedIps, allowedCidrs, blockedIps, and blockedCidrs
accordingly so IPv6 single-address CIDRs are classified consistently with IPv4.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/modules/reverse-proxy/ReverseProxyAccessControlRules.tsx (1)

144-148: ⚠️ Potential issue | 🟠 Major

IP-type rules still accept and preserve user-supplied CIDR suffixes.

validateRule accepts IP values with CIDR suffixes (e.g., 10.0.0.0/24) because cidr.isValidAddress treats CIDRs as valid, and the !rule.value.includes("/") guard here then skips the host-mask normalization, silently widening an "IP" rule into a range. Normalize unconditionally for type === "ip": strip any existing suffix and append /32 or /128.

Proposed fix

-      const suffix = rule.value.includes(":") ? "/128" : "/32";
-      const value =
-        rule.type === "ip" && !rule.value.includes("/")
-          ? `${rule.value}${suffix}`
-          : rule.value;
+      let value = rule.value;
+      if (rule.type === "ip") {
+        const raw = value.split("/")[0];
+        value = `${raw}${raw.includes(":") ? "/128" : "/32"}`;
+      }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/modules/reverse-proxy/ReverseProxyAccessControlRules.tsx` around lines
144 - 148, The current normalization logic uses the guard
!rule.value.includes("/") so user-supplied CIDR suffixes are preserved; change
it so that for rule.type === "ip" you always normalize: compute suffix =
rule.value.includes(":") ? "/128" : "/32", strip any existing CIDR by taking the
substring before the first "/" (or otherwise remove trailing "/..."), then set
value = `${strippedAddress}${suffix}`; update the assignment that currently uses
the conditional ternary (referencing rule.value, suffix, and value) and ensure
validateRule still accepts IP inputs before this normalization.